Add native macOS (Apple Silicon) support - #102
Conversation
f433a36 to
4e8fd0c
Compare
Support mac-os (apple silicon) target. Step 1 of 2 that results in a native Apple application Full disclosure - this was built with conjunction with Claude - but not pure vibe coded. I've reviewed and adjusted much of it once I broke the back of the problem. Locally I have a full working app, which will be delivered by a subsequent PR for PathOfBuilding-PoE2. ## Notable Changes (non-exhaustive) **LuaJIT:** Bumped to include arm64 mcode_alloc fixes. See: LuaJIT/LuaJIT#285 Without this, the resulting mac build had significant performance issues **Retina:** Changed the relevant cursor coordinates to support retina displays. Otherwise mouseclicks, and tooltip rendering windows were being cut off. **Clang:** Support for clang compilation, whilst maintaining MSVC ## Verification Built on OS X 26.5, and on Win. Both result in success and a working application
4e8fd0c to
f4d07fe
Compare
…JIT-fix approach Replace the custom-allocator + module-bisecting workaround stack with the upstream macOS approach from PathOfBuildingCommunity/PathOfBuilding-SimpleGraphic PR PathOfBuildingCommunity#102, which fixes the arm64/GC64 allocation problem at the source by pinning a patched LuaJIT (port 2026-03-30_1, ref 18b087cd) rather than working around it in the engine. Removed (no longer needed once LuaJIT is fixed correctly): - mac_gc64_alloc custom allocator + magic sentinel (ui_main.cpp) - mac_pload_* / bisect / coroutine module-loading machinery (~1050 lines across ui_api.cpp and ui_main.cpp) that worked around Data.lua load failures, themselves a symptom of the same GC64 bug - sys_IMain::launchCwd and the host argv handling in sys_main.cpp - mac/entry.cpp (win/entry.cpp already compiles on macOS via its visibility macros and _WIN32 guards, matching upstream) Adopted from PR PathOfBuildingCommunity#102: - Patched LuaJIT vcpkg port (2026-03-30_1) + arm64-osx triplet + version files; baseline bumped to 2026-05-22 - AppendLocalLuaSubdir() replacing inline package.path logic - Retina/HiDPI cursor scaling + GLFW_ANGLE_PLATFORM_TYPE_METAL (sys_video.cpp) - .app bundle base-path detection (sys_main.cpp) - Portable std::this_thread::sleep_for and size_t casts (r_main/r_texture) - VirtualScreenHeight() in r_font; base64/common include + guard fixes - Lua-cURLv3 luaL_setfuncs patch + CMake patch-application; WIN32-guarded lua-utf8/luasocket; ZSTD target selection Retained (our only divergence, additive and APPLE-guarded): - pob-host launcher executable (mac/host.cpp -> "Path of Building-PoE2") that links the dylib for a runnable dev binary; upstream defers this to a separate launcher repo. The host shifts argv itself so the engine stays identical to upstream. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E69xvgJuYgUaR1eHY3Qf3o
…ildingCommunity#102 Two fixes from nelkonandparker's macOS port (PathOfBuildingCommunity#102) that this branch lacked: - Scale cursor coordinates by the framebuffer/window-size ratio so clicks and tooltips align on HiDPI (Retina) displays; the ratio is 1.0 on Windows, leaving its behavior unchanged. - Explicitly select ANGLE's Metal backend on macOS (GLFW init hint, APPLE-guarded) and request the port's metal feature for osx in the vcpkg manifest. Co-authored-by: nelkonandparker <nelkonandparker@users.noreply.github.com>
|
Hi @nelkonandparker — I recently opened #111, which covers a lot of the same ground as this PR, and while comparing the two I found we'd independently arrived at several byte-identical fixes (the platform-sources CMake clobber, base64.c/common.cpp includes, the LuaJIT getenv NULL-guard). Two things your PR had that mine lacked — the Retina cursor-coordinate scaling and the explicit ANGLE Metal selection — are now in #111 with credit to you (Co-authored-by on commit 8102dab). A fuller hunk-by-hunk comparison is posted on #111 if you're curious how the approaches differ (mainly: in-tree launcher + overlay-triplet wiring + stock submodules vs. the companion-repo model). Since master's LuaJIT port moved and left this PR conflicting, consolidating into one PR seemed more useful to the maintainers than two competing ones — but if you're still active on macOS PoB, it'd be great to have a second pair of eyes (and a second test machine) on #111. Your unwind-mode LuaJIT patch and the Contents/Resources base-path redirect are the two pieces I didn't port; happy to discuss whether they should land too. 🤖 Generated with Claude Code |
Support mac-os (apple silicon) as a target. No workflow addition (would be a follow up PR). This doesn't actually result in any mac specific libs being built, as I didn't want to pollute the workflow in this PR
I've got a 'launcher'/'application' repo (with fork specific workflows) which uses the resulting dylibs to build into a final application:
https://github.com/nelkonandparker/PathOfBuilding-PoE2-macOS
Full disclosure - this was built in conjunction with Claude - but not pure vibe coded. I've reviewed and adjusted much of it once I broke the back of the problem.
Notable Changes (non-exhaustive)
LuaJIT:
Bumped to include arm64 mcode_alloc fixes. See: LuaJIT/LuaJIT#285
Without this, the resulting mac build had significant performance issues
Retina:
Changed the relevant cursor coordinates to support retina displays. Otherwise mouseclicks, and tooltip rendering windows were being cut off.
Clang:
Support for clang compilation, whilst maintaining MSVC
Verification
Built on OS X 26.5, and on Win. Both result in success and a working application